Summary

When a closure captured a variable by reference and that same variable was the target of a ??= assignment, e.g.

static $isSupported;
$isSupported ??= function (mixed $arg) use (&$isSupported): bool {
    return $isSupported($arg);
};

PHPStan inferred $isSupported as null inside the closure body and reported a false Trying to invoke null but it's not a callable. error. The exact same pattern written with a plain assignment (if (!isset($isSupported)) { $isSupported = function () use (&$isSupported) ... }) worked correctly. This change makes ??= behave like = for this case.

Changes

• src/Analyser/ExprHandler/AssignOpHandler.php: when evaluating the right-hand side of an Expr\AssignOp\Coalesce (??=) whose target is a simple variable, the handler now calls ExpressionContext::enterRightSideAssign($var->name, $expr->expr), the same call AssignHandler already makes for =/=&.
• tests/PHPStan/Analyser/nsrt/bug-13810.php: regression test asserting the closure type is inferred for a ??= recursive by-reference closure capture.

Root cause

The by-reference closure-use handling in NodeScopeResolver::processClosureExpr() reads inAssignRightSideVariableName / inAssignRightSideExpr from the current ExpressionContext. When the captured variable matches the variable currently being assigned, it resolves the variable to the assigned (closure) type inside the closure body, which is what makes $x = function () use (&$x) { ... } resolve $x to the closure.

Only AssignHandler (plain = / =&) populated that context. AssignOpHandler, which handles ??= together with the arithmetic/string compound operators, never called enterRightSideAssign(), so for ??= the context stayed empty and the by-reference variable fell back to its pre-assignment type (null after the ??= falsey filter). The fix populates the context for ??=, the only compound operator for which capturing-and-reassigning the same variable by reference is meaningful.

I probed the sibling assignment operators on the same axis: plain =/=& already set the context; the arithmetic and string compound ops (+=, -=, .=, ...) require the left-hand variable to already hold a non-closure value and cannot meaningfully reassign it to a captured closure, so they did not need the change.

Test

• tests/PHPStan/Analyser/nsrt/bug-13810.php asserts that inside $isSupported ??= function (mixed $arg) use (&$isSupported) { ... } the variable $isSupported is Closure(mixed): bool (previously null), and mixed~null in the enclosing scope after the ??=. Verified to fail before the fix (Actual: null) and pass after.

Fixes phpstan/phpstan#13810